第一部分 基础篇

系统的架构设计是每个系统构建过程及其关键的一部分，决定了系统是否能够被正确、有效地构建。

系统架构设计描述了在应用系统的内部，如何根据业务、技术、组织、灵活性、可扩展性以及可维护性等多重因素，将应用系统划分成不同的部分，并使这些部分相互分工，相互协作，从而为用户提供某种特定价值的方式。

随着面向对象分析、设计模式、企业架构模式等方法论的深入人心，从功能实现、代码组织的角度考虑，系统中不同职责的部分逐渐被划分到了如下三个部分：

• 表示层：聚焦数据显示和用户交互
• 业务逻辑层：聚焦业务逻辑处理
• 数据访问层：聚焦数据的存储与访问

每层负责的部分更趋向于具体化、细致化，这就是最初的软件三层架构，该架构解决了系统间调用复杂、职责不清的问题，更有效地降低了层与层之间的依赖关系。这是将系统在逻辑上进行划分，而不是物理上划分，即不同层的代码在进行编译、打包、部署后依然运行在同一个进程中。

对于这种功能集中、代码中心化、一个发布包、部署后运行在同一进程的应用程序，通常称之为单块架构应用。典型的单块架构应用，莫过于传统的J2EE项目所构建的产品或项目。

随着业务的扩大，需求的增加，单块架构很难满足业务快速变化的需求：一方面代码的可维护性、扩展性、灵活性在降低；另一方面系统的修改成本、构建以及维护成本在显著增加。

单块架构及其面临的挑战

三层应用架构

三层应用架构的发展

层能帮助我们划分出构成某整体事务的、上下互相支撑的不同部分。层的概念：

• 层能被单独构造；
• 每层具有区别于其它层的显著特点；
• 层与层之间能够互相连接，互相支撑，互相作用，相互协作，从而构成一个整体；
• 层的内部可以被替换成其他可工作的部分，但对整体的影响不大。

Web程序开发早期收到面向过程思维以及设计方式的影响，所有的逻辑代码调用相互交错，错综复杂，如早期的PHP、JSP以及ASP便是将所有的页面逻辑、业务逻辑以及数据库访问逻辑放在一起，即一层架构。

随着Java、.NET的发展，数据访问部分的代码逐渐有了清晰的结构，但表示逻辑和业务逻辑依然交织在一起，即二层架构。

随着面向对象分析、面向对象设计、面向对象原则、设计模式、企业架构模式等理念以及方法论的不断发展，从而为用户提供以及有效组织软件结构的考虑，Web根据职责的不同逐渐被定义在不同的层次，每一层负责的部分更趋向于具体化、细致化，即三层架构。

什么是三层架构

三层架构通常包括表示层、业务逻辑层以及数据访问层、

• 表示层

表示层指的是用户使用应用程序时与其交互操作的部分，通过该部分进行交互并获取期望的结果。目前用户接口大部分为Web形式，也可以是桌面软件形式。

• 业务逻辑层

业务逻辑层是根据用户输入的信息，进行逻辑计算或业务处理的部分。业务逻辑层主要聚焦应用程序对业务问题的逻辑处理，以及业务流程的操作，它是大部分软件系统区别于其他系统的核心。

• 数据访问层

在用户同应用程序交互的过程中就会产生数据，这类数据需要通过某种机制被有效地存储，以便将来使用。这种机制或方法就是数据访问层最关注的部分。它关注的是对原始数据的操作，而不是对数据存储介质，即数据库的操作。

三层架构的优势

三层架构一方面解决了应用程序中代码间调用复杂、代码职责不清的问题。其通过在各层间定义接口，并将接口与实现分离，可以很容易地利用不同的实现来替换原有层次的实现，从而降低层与层之间的依赖。这种方式不仅有利于帮助团队理解整个应用架构，降低后期维护成本，同时也有利于制定整个应用程序架构的标准。

另一方面，三层架构的出现从某种程度上解决了企业内部如何有效根据技能调配人员，提高生产效率的问题。

单块架构

什么是单块架构

三层架构将应用从逻辑上分为三层，但最终经历编译、打包、部署后，不考虑负载均衡以及水平扩展的情况，最终还是运行在同一台机器的同一个进程中。对于这种功能集中、代码和数据中心化、一个发布包、部署后运行在同一进程的应用程序，我们称之为单块架构应用。

单块架构的优势

• 易于开发

• 易于测试

  由于所有功能都运行在一个进程中，启动开发环境或将发布包部署到某一环境，一旦启动该进程，就能立即开始策测试。

• 易于部署

所有功能最终都会被打成一个包，因此只需复制该软件包到服务器相应的位置即可。最简单的方式是使用scp远程复制到指定目录下。

• 易于水平伸缩

单块架构面临的挑战

• 维护成本增加

随着应用程序功能越来越多，团队越来越大，相应的成本必然增加。此外当出现缺陷时，由于引起缺陷的原因组合会比较多，这将导致修复缺陷的成本增加，周期增长。

另外随着代码量增加，在开发人员对全局功能缺乏深度理解下，修复一个缺陷，可能引入其他缺陷。

• 持续交付周期长

随着应用程序的功能越来越多，代码越来越复杂，构建和部署的时间也会响应增加。

• 新人培养周期长

随着应用程序的功能越来越多，对于新加入的团队成员而言，了解行业背景、熟悉应用程序业务、配置本地开发环境这些任务将消耗其大量的时间。

• 技术选型成本高

传统的单块架构系统倾向于采用统一的技术平台或方案解决所有问题。因此对于单块架构的应用而言，初始的技术选型严重限制了将来采用不同语言或框架的能力。

• 可扩展性差

（1）垂直扩展：所有代码都运行在同一台服务器上，将会导致应用程序扩展非常困难。相对而言垂直扩展是最容易的，但成本会越来越高；

（2）水平扩展：水平扩展的通常方法是建立一个集群，通过在集群中不断添加新节点，然后借助前端的负载均衡器，将用户请求根据某种算法合理地分配到不同的节点上。

对于单块架构而言，所有程序代码都运行在服务器同一个进程中，则会导致应用程序的水平扩展成本高。比如某部分功能是内存密集型，另一个部分是CPU密集型，当扩展时就需要新节点必须有足够的内存和强劲的CPU。

• 构建全功能团队难

单块架构的开发模式在分工时以进呢个为单位，这样的分工会导致任何功能的改变都需要跨团队沟通和协调。

This blog is under a CC BY-NC-SA 3.0 Unported License
本文链接：http://yov.oschina.io/article/微服务/Micro Service/基础篇01--单块架构及其面临的挑战/